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(54) Method and apparatus for synchronizing firmware 



(57) The invention is a method and apparatus for 
Synchronizing firmware associated with a first computer 
device and a second computer device, such as a server 
and a client computer, in accordance with one embodi- 
ment of the invention, the method comprises the steps 
of providing information regarding a characteristic of the 
firmware associated with the first and second devices, 
comparing the provided firmware information to deter- 
mine if the firmware is synchronized, and associating 



new firmware with the second device to synchronize the 
firmware if the firmware is found to not be synchronized 
in the comparing step. In one or more embodiments of 
the invention, the firmware associated with the second 
device is not modified unless the integrity of the 
firmware to be installed on the second device is verified 
using a digital signature. 
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Description 

BACKGROUND OF THE INVENTION 

1 . FIELD OF THE INVENTION 

[0001] This invention relates to computing devices, 
and more particularly, to a method and apparatus for 
synchronizing the firmware associated with such 
devices. 

[0002] Portions of the disclosure of this patent doc- 
ument may contain material that is subject to copyright 
protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent docu- 
ment or the patent disclosure as it appears in ihe Patent 
and Trademark Office file or records, but otherwise 
reserves all copyright rights whatsoever. Sun Microsys- 
tems, Java and all Java-based trademarks and logos 
are trademarks or registered trademarks of Sun Micro- 
systems, inc. in the United States and other countries. 
All SPARC trademarks are usad under license and are 
trademarks or registered trademarks of SPARC Interna- 
tional in the United States and other countries. Products 
bearing SPARC trademarks are based upon an archi- 
tecture developed by Sun Microsystems. Inc. 

2. BACKGROUND ART 

[0003] tn many electronic information communica- 
tion paradigms, first and second devices communicate 
with one another even though they may be physically 
remote. One such arrangement is thai where a remote 
client computer station oc*mmunicates with another cli- 
ent computer station or a central server. 
[0004] Generally, in order for the devices to commu- 
nicate, they must interact by way of a common protocol, 
otherwise the devices will not "understand" one another, 
h is often difficult, however, to ensure that both devices, 
such as a server and a remote workstation as described 
above, are arranged to utilize the same protocol. An 
incompatibility of the protocol between two devices may 
arise from changes in the protocol of one but not both 
devices. A change in protocol may arise when the 
firmware, such as software, is upgraded on one but not 
all devices to a more recently released or "newer" ver- 
sion. 

[0005] As an example, in the server/remote work- 
station arrangement described above, it is common for 
the users or clients of the remote workstation(s) to 
upgrade the version of the software implemented at only 
their workstation. Upgrades to Ihe server may be con- 
trolled by a completely independent entity, such as a 
system administrator, and not be coordinated at all with 
changes in the firmware (and thus proioool) at the 
remote workstataon(s). 

[0006] tt may be possible to manually compare the 
firmware "version" information in order to determine if 
the workstation and server are operating with the same 
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protocol. H is often impractical to change the protocol of 
the server, and as such it is common for the rerooie 
workstation to be updated with the appropriate version 
of the firmware. Thus, if a user determines that the 

s firmware at the workstation is "older," in the sense of a • 
having numerically lower version number than that of 
the version operated by the server, the user may update 
software or firmware on the workstation. There are 
numerous pitfalls associated with such a procedure. 

10 [0007] A first problem is simply that there is no refi- 
abie mechanism for ensuring that multiple workstations 
and the server's) are ail continuously updated. The 
above-described update process requires a particular 
person or persons to be response tor updating the 

ts firmwa/e associated with each workstation. Lapses in 
ths update process may render one or more worksta- 
tions associated with a network inoperable. 
[0003] Problems may arise when a user attempts to 
install or update firmware on their workstation. One 

so problem arises when the upload is interrupted, such as 
in the case of a power failure, ff the updated firmware ts 
only partially written to the memory of the remote work- 
station when the interruption occurs, the workstation is 
often disabled because the workstation's protocol 

zs remains incongruous with the server with only a partial 
update of the firmware. The disabling of the workstation 
may also occur in similar fashion if there is an error in 
the firmware toad module. 

[0009] Another problem associated with updating 
30 firmware of a remote workstation using an upload 
arrangement arises from security risks. Unauthorized 
persons can force undesirable software onto the work* 
station during the upload of the desired updated 
frmware, or may block the upload process- Diagnostic 
as mechanisms which allow the insertion of code from an 
external source are particularly susceptible to attack. 

SUMMARY OF THE INVENTION 

40 [0010] The invention is a method and apparatus tor 
synchronizing firmware, such as versions of software, 
associated with a first computer device and a second 
computer device, 

[0011] In accordance with one embodiment of the 
45 invention, the method comprises the steps of transmit- 
ting Information regarding a characteristic of the 
firmware associated with the first device from the first 
device to the second device, comparing the firmware 
information transmitted from the first device to informa- 
so tion regarding the same characteristic of the firmware 
associated with the second device, and associating new 
or different firmware with the second device if the char- 
acteristics associated with the firmware of the first and 
second devices are not the same to thereby synohro- 
55 ntze the firmware associated with the two devices. 
IP012] In accordance with one or more embodi- 
ments of the invention, in the event the firmware associ- 
ated with the second device is not the same as that of 
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the first device, then the firmware associated with the 
second device is modified to match or synchronize with 
thai of the first device by loading updated firmware to 
the second device. 

[0013] In accordance with one or more embodi- 
ments of the invention, updated firmware is not installed 
onto the second device until the integrity of the updated 
firmware is verified- This prevents the introduction of 
unwanted code, such as a virus, untrusted code, or 
other unauthorized code to the system tn one embodi- 
ment the firmware to be installed to the second device 
comprises a load module having a private key associ- 
ated therewith and the step of verifying comprises using 

a public key to verify the private key. 

[0014] tn accordance with one or more embodi- 
ments or the invention, the first device is a server which 
is capable of providing services to a number of interface 
devices, and the second device comprises one of such 
interface devices- In accordance with one embodiment, 
the second device includes a memory element onto 
which the firmware is loaded and a read-only memory 
area which includes emergency firmware for ensuring 
the device is not rendered inoperative in the event 
updated firmware »s not properly or completely installed. 
10015] In one or more Bfnbodiments, computer 
hardware and/or software is arranged to perform the 
method of the invention, 

[0016] Further objects, features and advantages of 
the invention wHI become apparent from the detailed 
description of the drawings which follows, when consid- 
ered with the attached figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

I0O17] 

FIGURE 1 illustrates a computer architecture or 
system with which the present invention has partic- 
ular utility. 

figure 2 Is a Uock diagram illustrating one 
embodiment of a Human Interface Device of the 
system illustrated in Figure 1; 

FIGURE 3 is a flowchart illustrating one embodi- 
ment of a method of the invention; 

FIGURE 4 re a flowchart illustrating one ernbodr- 
mertt of a method of updating f irmware in accord- 
ance with the method illustrated in Figure 3: 

FIGURE 5 is a flowchart illustrating one embodi- 
ment of a method of verifying firmware in accord- 
ance with the method illustrated in Figure 4: 

FIGURES 6<aMc) illustrate embodiments of 
firmware load modules in accordance wfth embodi- 
ments of the invention; 
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FIGURE 7 illustrates an embodiment of a rnemory 
arrangement onto which a load module may be 
installed; 

s FIGURE 8 is a flowchart illustrating a boot 

sequence in accordance with a method of the 
invention; and 

FIGURE 9 is a btock diagram of one embodiment of 
10 a computer system capable of providing a suitable 
execution environment tor an embodiment of the 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

is 

[001 8] The invention is a method and apparatus for 
synchronizing the firmware associated with two or more 
computers or other devices which era to communicate 
by electronic means. In the following description, 

so numerous specific details are set form in order to pro- 
vide a more thorough description of me present inven- 
tion. It will be apparent however, to one skilled in the 
art, that the present invention may be practiced without 
these specific details. In other instances, well-known 

25 features have not been described in detail so as not to 
obscure the invention. 

Environment 

30 [0019] As described in more detail below, embodi- 
ments of the invention have application to a variety of 
first and second devices arranged to communicate elec- 
tronically. One computer system architecture or system 
with which the invention is applicable is the environment 

35 described in Figure 1 . In this system, the at least one 
first device comprises a computer detfce in the form of 
a central computer data source and the at least one 
second device comprises a computer device in the form 
of a "Human interface Device' (HID). As described in 

4c more detail below, in this architecture, some or all com- 
puting is done by the central data source or service, with 
the output of the data source provided to a HID. The HID 
is capable of receiving data and displaying data. 
[0020] In the system illustrated In Figure 1 , the cen- 

4S traj data source comprises one or more computational 
service providers or servers 1 00. The one or more serv- 
ice providers 100 communicate with one or more HIDs 
through some interconnect fabric 101, such as a net- 
work- 

so [0021] In this arrangement the computational 
power and state maintenance is found in the service 
providers. The services are not tied to a specific compu- 
ter, but may be distributed over one or more traditional 
desktop systems such as the computer device 

55 described in connection with Figure 9 below. One com- 
puter may have one or more services, or a service may 
be irnpternerrted by one or more computers. The service 
provides computation, state, and data to the HIDs and 
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tha service is under the control of a common authority 
or manager. In Figure 1 . tha services are found on com- 
puters 110. 1 11, 112, 113 and 114. Tha central data 
source can also be providing data that comes "from out- 
side of the central data Source, such as for example, the 5 
Internet or world wide web. 

[0022] It is the responsibility of tha service to handle 
communications with the HIO that is currently being 
used to access the given service. This involves taking 
the output from the computational service and convert- w 
ing it to an acceptable protocol for the HIO, A method tor 
insuring the compatibility of both participants using this 
protocol is described in detail below. 
[0023] The interconnect fabric is any of multiple 
suitable communication paths for carrying data between is 
the services and the HIOs. In one embodiment the inter* 
connect fabric is a local area network implemented as 
an Ethernet network. Any other local network may also 
be uftized. 

[0024] In one embodiment, the interconnect fabric so 
provides actively managed, low-latency, high bandwidth 
communications between the HID and the services 
being accessed. 

[0025] The HID is the means by which users access 
computational services provided by the servers or serv* zs 
ices, and as such the HID may also be referred to as a 
client or user workstation or terminal. Figure 1 illustrates 
HIDs 121. 122 and 123. In the embodiment illustrated, a 
HID consists of a display 1 26, a keyboard 124. a mouse 
125, and audio speakers 127. The HIO includes the to 
electronics needed to interface these devices to the 
interconnection fabric and to transmit to and receive 
data to and from the services, 
[0026] A block diagram of one embodiment of a HID 
is illustrated in Figure 2. The components of the HIO are ss 
coupled internally to a PCI bus 212. A network control 
block 202 communicates with the interconnect fabric, 
such aa an Ethernet, through line 214. An audio codec 
203 receives audio data on interlace 2 1 6 and is coupled 
to block 202. USB data communication is provided on 40 
lines 213 to USB controller 201 . 
[0027] An embedded processor 204 may be, tor 
example, a Sparc2ep™ with coupled flash memory 205 
and DRAM 206. The USB controller 201, network con- 
troller 202 and embedded processor 204 are all coupled 45 
to the PCI bus 212. Also coupled to the PCI 212 ia the 
video controller 209- The video control er 209 may be 
for example, an ATI Ragel28 frame buffer controller (or 
any other suitable control er) that provides SGA output 
on fine 21 5. NTSC or PAL data la provided into the video so 
controller through video decoder 210. A smartcard 
interface 208 may also be coupled to the video control- 
ler 209. 

[0028] Alternatively, the HID can be implemented 
using a single chip solution including the necessary 55 
processing capability. 

[0029] This architecture or system is descrbed in 
greater detail in LIS. Patent Application Serial No. 



00/063.335. assigned to the present assignee, filed 
April 20, 1998. entitled "Method and Apparatus For Pro- 
viding A Virtual Desktop System Architecture - incorpo- 
rated herein by reference. 

Method for Synchronizing Firmware 

[0030] One or more embodiments of the invention 
comprise a method for synchronizing firmware associ- 
ated with at least two devices. 

[0031] as used herein the lerm nirmware" is 
intended to include, but not be Srnited to. any element 
arranged to permit a device to transmit and/or receive 
data or information, such as software or applications 
defining a protocol by which information is sent or 
received. As used herein the term "synchronize - is 
intended to include, but not be limited to the act or result 
of causing two devices or the elements associated 
therewith to have the capacity to compatibly transmit 
and receive information or data 
[0032] One ernboolment of the invention wilt be 
described in conjunction with the system described 
above and illustrated in Figure 1. In accordance with this 
embodiment, and as illustrated in Figure 3. in a first step 
S1 , the second device is started. In one or more embod- 
iments, such a step may comprise booting or powering 
up a HID as described above- 
[0033] In a step S2, information regarding the 
firmware associated with the first and second devices is 
provided- In one or more embodiments, the provided 
information is set of parameters comprise data regard- 
ing a common characteristic of the firmware associated 
with each device, m one or more embodiments, this 
characteristic information comprises a string that repre- 
sents the current software revision or version or edition 
associated with the device. 

[0034] in one or more embodiments, this step 
includes the step of the first device which is to provide a 
service to the HID, such as a central server, sending a 
set of initial protocol parameters to the HID upon 
request. The HID or second device may provide the 
Information in memory. When the server or other first 
device provides the information to the second device, 
the data may be sent to the HfD upon the HID's sending 
a request, such as at boot- up 

[0035] Of course, it wil be appreciated thai the sec- 
ond device, such as a HID, might be arranged to send 
the information to the server or ether first device. 
[0036] A step S3 of the method comprises compar- 
ing the provided information to determine if the firmware 
is synchronized. In one or more embodiments, the step 
comprises the second device, such as a HID. compares 
Hs firmware information, such as a version of particular 
software, to that Indicated by the set of parameters sent 
by the first device, such as a central server. In one or 
more emtxxfiments, this comparison comprises the 
step of determining rf the version of the software of the 
HID is the same as that indicated by the centra! server. 
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The comparison step may con prise determining rf lha 
data string representing the version of the firmware 
associated with the server is identical to the data string 
representing the version of the firmware associated with 
the HID. 

* [0037] If the versions of the software are the same 
or matching (i.e. the firmware is already synchronized) 
then in a step S5, the synchronization sequence ends. 
If the versions are not the same, then in a step S4, the 
lirmware associated with the HID is updated and then in 
a step S5 the sequence ends, 

[0038] One embodiment of a method by which the 
firmware associated with the HID is updated (as in step 
S4 of Figure 3) wfll be descnoed In conjunction with Fig- 
ure 4. 

[0039] *i a first step 5401, the central sewer or 
other service instructs the HID which version of the 
firmware the HID is to implement and where to obtain 
the necessary firmware. For example, the central server 
may instruct the HID to obtain version XX.Y of particular 
software from a particular firmware computer or server. 
[0040] In a step S4Q2. the HID seeks the appropri- 
ate firmware server and determines H the firmware 
which is to be obtained is vaBd. In one or more embodi- 
ments, where the firmware is obtained in the form of a 
load module which is loaded into memory associated 
with the HID from the server, the HID determines H the 
load module is the correct version, is legitimate, uncor- 
rupted and the like, If sain a step S403 the HID uploads 
or updates the firmware and installs rt. If not, the 
firmware update is terminated. In such an event, the 
HID may be arranged to requests from the central 
server or service another server from which the desired 
firmware may be obtained. 

[0041] One embodiment of q method by which an 
HID determines if a load modute is legitimate (step 
S402 of Figure 4) will be described in more detail with 
reference to Figure 5. 

[0042] in a first step S402A, the HID obtains a load 
module from the firmware server and transfers it to 
memory, in one or more embodiments, the type of 
memory to which the load mod Lie is transferred is a 
temporary memory or similar storage location. For 
example, the HID may load the toad module to DRAM 
(such as DRAM 206 illustrated In Figure 2 and 
described above). 

[0043] In a step S402B, the load module is decom- 
pressed, if necessary. 

[0044] In a step $4020, the HID vermes at least one 
identifying element associated with the load module. In 
one or more embodiments, the step comprises verifying 
at least a digital signature associated wrth the load mod- 
ule. In one or more embodiments, the step cornprises 
verifying both a header and a signature associated with 
the load module. 

[0045] tn one or more embodiments, each toad 
module is provided with a header which contains one or 
more pieces of information, such as the size of the load 
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module. In the event that the HID verifies the haade* 
information, this aspect of the verification step is com- 
pleted, rf not. the HID will not execute the load module, 
and the HID may recontact the central server or other 
s provider for information as to where to attempt to obtain 
a vafid load module. 

(0046] In one or more embodiments, each load 
module includes a digital signature in the form of a pri- 
vate key or code which is associated with the load mod- 

io uJeby the manufacturer. The client (i.a HID) is provided 
with a public key associated with the private key. the 
public key used to verify the signature generated by the 
private key. If the digital signature id verified, then this 
portion of the verification step is complete. It not the 

15 HID win not execute the load module, and the HID may 
recontact the central server or other provider for infor- 
mation as to where to attempt to obtain a valid load 
module 

[0047] As is well known, there are a variety of man- 
£0 ners for implementing such a private/public key arrange- 
ment in one or more embodiments, the keys are 
encrypted to ensure their integrity. 
[004fi] Figures 6(aHc) illustrate load module for- 
mats which include a header and digital signature as 
25 described above. Of course, the load modules may be 
arranged in a variety of manners and still provide the 
verification feature disclosed above. If the firmware 
which is being installed or uploaded to the device is not 
tn the form of a load module, the firmware is still desira- 
30 bly configured to include information such as that 
deserted above for ensuring the integrity of the 
firmware. 

[0049] If the load module is verified, then and only 
then is the load module is accepted, such as by writing 

35 rt to a memory associated with the HID, such as the 
read/Write portion of the flash 205 of the HID. In this 
arrangement, the load module is not written to the flash 
unless the load module is verified. 
[0050] As another aspect of the invention, there is 

49 provided a method for ensuring that a partial or other- 
wise Incomplete update of the firmware does not render 
the HID inoperative. In accordance with mis method, the 
HID includes a means for starting or booting the HID in 
the event certain of the firmware associated with the 

45 HID is corrupt. In one or more embodiments, this means 
compr ises an emergency trivial file transfer protocol 
(TFTP) loader eppfication associated with the HID. In 
one or more embodiments, the emergency loader appli- 
cation is stored in a write-protected sector of the HID/fi 

bo flash 205. 

[0051 ] Figure 7 illustrates an arrangement of a flash 
memory 205 for vnplementing this method. As illus- 
trated therein, the flash has a first read/write region 710 
and a second read-only region 712. The read-only 

55 region 71 2 includes a stand-alone TFTP boot or "emer- 
gency loader" 714 program. This emergency loader pro- 
gram 714 includes a protocol for transferring files, such 
as the desired updated firmware load module 
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[0052] This f igure also illustrates that the load mod- 
ule verification steps of the method may be associated 
with an application which is stored in a memory assod- 
ated with the HID. In the embodiment illustrated, the 
application is stored in the read-only region 712 of the 5 
HID's flash memory 205. and cpied to HID memory on 
power- up, 

[0053] In accordance with the method, the emer- 
gency loader 714 can not be overwritten, even with a 
load module which is being uploaded in order to syrv 10 
chronize firmware. In the event of a failure in a normal 
boot application stared in the main read/write region 
710, the emergency loader 714 may be utilized to con- 
tact the central server to obtain updated firmware in the 
form of a toad module. In the event the load module is 15 
obtained in this manner, one embodiment of the method 
includes the step of performing a reboot of the HID. 
whereby the updated application will run instead of the 
emergency loader after the load module is successfully 
installed. 20 
(0054] In accordance with the above-described 
method, the only time an HID can not be used on 
demand is in the event a firmware update was unsuc- 
cessful and the emergency loader is unable to get a 
good load from a firmware server. In such an event ?s 
however, the HID is only temporarily disabled until the 
emergency loader is able to contact a firmware server 
and obtain and complete an update of the firmware. 
[005$] Figure 8 is a flowchart illustrating an embod- 
iment of a boot sequence for a HID incorporating the 30 
method described above. In a step S801. the HID is 
powered, booted up or reset. In a step $802 an initiali- 
zation and testing sequence is completed, as is well 
known in tha art of computer devices. In a step S803 it 
is determined if there is an external PROM. If yes. then 3* 
in a step $804 the information contained on the external 
PROM is decompressed into RAM (such as DRAM 206 
illustrated in Figure 2). The information contained on the 
external PROM may comprise a load module compris- 
ing firmware. In step S805. it is determined if the load 40 
module has a valid signature (as descrtoed above in 
conjunction with step S402C). tf so, the load module 1$ 
executed in a step S607. 

[0056] If in step S80S H is determined that the sig- 
nature associated with the load module is not vaKd or if 4S 
in step SS03 it is determined that there is no external 
PROM, (hen in a step S807 H is determined if there is a 
vafid read/write flash, ft is noted that in most instances 
an external PROM will not be present. The external 
PROM may be associated with the HID whan the HID is so 
initialized or started the very first time, or when the HID 
is rendered completely inoperable through destruction 
of aR code on its flash. 

[0057] ff in step S807 it is determined that there is a 
valid read/write flash, i.e. that the proper firmware is 55 
present h the readAwrrte section at the HIDs flash, tien 
in a step SS08 the firmware is decorrpressed into RAM. 
In a step 6809 it is then determined if the firmware, such 



as a load module, has a valid signature (as described 
above in conjunction with step 5402C). If so. the load 
mod ufe is executed in a step S810. 
[0053] If the signature is not valid, then in a step 
S811 it is determined if the HID was started cold or 
warm (i.e. cold or warm boot). If the signature is invalid 
and the boot was a warm boot then in a step S812 the 
sequence ends with an indication to a user of failure and 
the need to reboot the HID, such as by Winking an LED 
indicator. 

[0059] tf the boot sequence was cold (i.e. warm = 
no) then in a step S813 the emergency boot sequence 
is started by decompressing the TFTP boot information 
to RAM. In step S814 it Is determined if the signature 
associated with the information loaded into RAM is 
valid If not, then in step S812 the sequence ends as 
described above (a bad signature indicating that the 
f irmware has been compromised). 
[0060] r? the signature is valid, then m a step $815 
the T FTP boot is executed- As described above, the 
TFTP boot is designed to seek a new copy of the load 
modulo. In a step S816 it is determined if the load mod- 
ule is found and uploaded- » not then in a step S81 7 the 
sequence ends in a similar manner to that associated 
with step S81 2. 

[0061] If a valid upload of the load module is 
obtained, then in a step S818 the signature associated 
with the load module is verified If in step S8T9 it is 
determined that the signature is invalid, the sequence 
ends in step S81 7. rf the signature is valid, indicating the 
integrity of the load module, then in a step 5820 the load 
module is written to the read/write portion of the flash of 
the HID. and a reset occurs. 

[0062] It should be understood that the load module 
may be obtained from a variety of sources. In the above- 
descrtoed sequence, the load module is first obtained 
from an external PROM. Of course, the load module 
might be obtained from a network or a variety of other 
types of mem ory de vices. In addition, while the load 
module and TFTP emergency boot have been 
desortoed as associated with flash-type memory, they 
may be associated with a variety of other types of mem- 
ory. A load module may also be obtained through a 
diagnostic port associated with the HID or other device. 
Regardless of the source, however, the integrity or valid- 
ity of the firmware is always confirmed through the use 
of a gital signature authorization. 
[0063] in accordance with the above-described 
method, the server or other central device is arranged to 
tjxtete or synchronize the firmware of the remote 
device, or HID. In this arrangement the HID or other 
remote device is prevented from updating or changing 
the firmware which is on the central device or server. 
(0064] In accordance with the above-described 
method, if the firmware associated with a central device, 
such as a server, is updated, then all of the remote 
devices such as HIDs are automatically updated as 
well. In one or more embodiments of the invention. 
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instead of the update or synchronization process only 
occurring after the HID or other device is powered or 
booted up, the synchronization may be arranged to 
occur at a wide variety of times. For example, a server 
may be arranged to send a signal to each HID to trigger 
the update process at predetermined intervals. 
[0065] In accordance with one aspect of the above- 
described method, the firmware associated with the two 
devices is synchronized regardless of which device has 
the older or newer version. This is because synchroni- 
zation occurs whenever the firmware associated with 
the two devices is not identical, not just when one 
device, such as the HID, has a numerically lower or 
higher version that the central device. Thus, even It the 
server has an older version of the firmware than the 
HID. the firmware associated with the HID wiU be Syn- 
chronized with that of the server by installing the older 
version of the firmware onto the HID. This ensures that 
the server and all HIDs are always operating with com- 
mon firmware. 

[0066] While in the method described above the 
firmware which is described as being loaded to the HID 
is the same version as that of the first device, such as a 
server, such need not be the case. As provided above, 
an aspect of the invention is to synchronize the devices 
so thai they utilize a protocol which permits compatible 
communication. In some instances, an HID and a server 
may operate with different versions of firmware which 
still achieve this goal. Thus, as other aspects of the 
invention, the firmware which is uploaded to an HID 
need to be the same as that of the server, as long as the 
uploaded firmware uftimatefy provides the desired syn- 
chronization in protocol, In this regard, in the "compar- 
ing" step (S3 in Figure 3) it is only necessary to 
determine if the firmware is matching or the same such 
as to determine whether the firmware is already syn- 
chronized. 

[0067] By way of example, if versions e.oa and 6.0b 
of particular firmware are cornpatibfe, the HID may be 
arranged to compare a string X.X (eliminating the a and 
b) provided by the server to its version to determine if 
the firmware is synchronized. If the HID is operating 
with non-compatible version S.Oa, then the strings 5.0 
and 6-0 will not match, indicated that the firmware is not 
synchronized and requiring the HID to install new 
firmware. The newly installed or uploaded firmware may 
be version 6.0a or 6.0b. regardless of what version the 
server is using, since either version provides synchroni- 
zation. 

[0068] While methods of the invention have been 
described in association with the system illustrated in 
Figure 1. as described above, embodiments of the 
invention may be associated with a wide-variety of other 
systems or devices, such as general purpose computer 
900 illustrated in Figure 9 and described in more detail 
below. Thus, an ernbodimerrt of the invention can be 
implemerrted as computer software in the form of com- 
puter readable code executed on orxnputer 900 or other 
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device, or In the form of bytecode class files executable 
within a Java™ runtime environment running on such a 
computer or other device, or in the form of byteccdes 
running on a processor (or devices enabled to process 
5 byteccdes) existing in a distributed environment (e.g.. 
one or more processors on a network). 
[0069] Referring to Figure 9, the general purpose 
crjmputer 900 includes a keyboard 910 and mouse 91 1 
coupled to a system bus 91 8. The keyboard and mouse 
10 ere for introducing user input to the computer system 
and communicating that user input to processor 913. 
Other suitable input devices may be u$ed in addition to, 
or In place of. the mouse 911 and keyboard 910. I/O 
{input/output) unit 9 1 9 coupJ ed to system bus 91 8 repre- 
ss sents such I/O elements as a printer, A/V (audio/Video) 
I/O. etc. 

[0070] Computer 900 includes a video memory 

914. main memory 915 and mass storage 912. all cou- 
pled to system bus 91 8 along with keyboard 910. mouse 

20 911 and processor 913. The mass storage 912 may 
include both fixed and removable media, such as mag- 
netic, optical or magnetic optical storage systems or any 
Other available mass storage technology. Bus 918 may 
contain, tor example, thirty-two address lines for 

as addressing video memory 914 or main memory 915. 
The system bus 91 8 also includes, for axampJ e, a 64-bit 
data bus for transferring data between and among the 
components, such as processor 913, main memory 

915. video memory 914 and mass storage 91 2. Afterna- 
30 tivefy, multiplex data/address lines may be used instead 

of separate data and address Knee. 
[0071] In one embodiment of the invention, the 
processor 913 is a microprocessor manufactured by 
Sun Microsystems. Inc., such as the SPARC* - mfcro- 

3s processor, or a microprocessor manufactured by 
Motorola, such as the 680X0 processor, or a microproc- 
essor manufactured by Intel, such as the 60X86. or Pen- 
tium processor. However, any other suitable 
microprocessor or microcomputer may be utilized. Main 

40 memory 915 is comprised of dynamic random access 
memory (DRAM), Video memory 914 is a dual-ported 
video random access memory. One port of the video 
memory 914 is coupled to video amplifier 916. The 
video amplifier 916 is used to drive the cathode ray tube 

4S (CRT) raster monitor or display 91 7. Video amplifier 91 6 
is well known in the art and may be implemented by any 
suitable apparatus. This circuitry converts pixel data 
stored in video memory 914 to a raster signal suitable 
tor use by monitor 917. Monitor 917 is a type of monitor 

so suitable for displaying graphic images. 

[0072] Computer 900 may also indude a communi- 
cation interface 930 coupled to bus 918. Communica- 
tion interface 920 provides a two-way data 
communication coupling via a network link 921 to a local 

s$ network 922. For example, if communication interface 
920 is an integrated services digital network (ISDN) 
card or a modern, communication interface 920 pro- 
vides a data communication connection to the corre- 
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spending type of lefephono line, which comprises part 
of network link 921 . If communication interface 920 is a 
local area network (LAN) card, cxxrimunicatton interface 
920 provides a data communication connection via net- 
work link 021 to a compatible IAN. Wireless links are 5 
also possible. In any such implementation, communica- 
tion interface 920 sends and receives electrical, electro- 
magnetic or optical signals which carry digital data 
streams representing various types of information, 
[0073] Network link 921 typically provides data 10 
communication through one or more networks to other 
data devices. For example, network fink 92i may pro- 
vide a connection through local network 922 to local 
server computer 923 or to data equipment operated by 
an Internet Service Provider (ISP) 924. ISP 924 in turn 15 
provides data cornrnuntcaiion services through the 
world wide packet data communication network now 
commonly referred to as the "Internet* 925. Local net- 
work 922 and Internet 925 both use electrical, electro- 
magnetic or optica) signals which carry digital data so 
streams. The signals through the various networks and 
the signals on network Bnk 921 and through communi- 
cation interface 920, which carry the digital data to and 
from computer 900. are exemplary forms of carrier 
waves transporting the information. 25 
[0074] Computer 900 can send messages and 
receive data, md uriing program code, through the net- 
work(s), network link 9£i, and communication interface 
920- In the Internet example, remote server computer 
926 might transmit a requested code for an appication 30 
program through Internet 925, ISP 924, local network 
922 and communication interface 920. 
[0075] The received code may be executed by proc- 
essor 913 as H is rece«ved, and/or stored in mass stor- 
age 912, or other non-volatile storage for later sff 
execution. In this manner, computer 900 may obtain 
application code in the form of a carrier wave, 
[0076] Application code may be embodied in any 
form of computer program product. A computer program 
product comprises a medium configured to store or 40 
transport computer readable code, or In which computer 
readable code may be embedded. Some examples of 
cornputer program prooVrcte are CD-ROM disks, ROM 
cards, floppy drsfcs, magnetic tapes, computer hard 
drives, servers on a network, and carrier waves. 45 
[0077] Trie computer systems described above are 
for purposes of example only. An embodiment of the 
invention may be implemented in any type of computer 
system or prooramming or processing environment. 
[0078] As will be appreciated by those of skill in the so 
art there is a wide variety of conf igurations for hardware 
and software lor accomplishing the method of the inven- 
tion other than that described above. 
[0079] Of course, the foregoing description is that of 
preferred ernbodirnents of the invention, and various ss 
changes and modifications may be made without 
departing from the spirit and scope of the invention, as 
defined by the claims. 
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[0080] The features - disclosed in iha foregoing 
description, in the claims and/or in the accompanying 
drawings may, both separately and in any combination 
thereof, be material for realising the invention in diverse 
forms thereof. 

Claims 

1- A method of synchronizing firmware associated 
with a first cornputer device and a second computer 
device comprising the steps of: 

providing information regarding a characteristic 
Of the firmware associated with said first 
device; 

providing information regarding a characteristic 
of the firmware associated with said second 
device, said characteristic of said firmware 
associated with said second device being com- 
mon to said characteristic of said firmware 
associated with said first device; 
cornparing said firmware information associ- 
ated with said first device to information regard- 
ing said firmware associated with said second 
device to determine if said characteristic is 
matching: and - 

associating second firmware wrfh said second 
device if said characteristics associated with 
said firmware of said first and second devices 
are not matching, whereby said firmware asso- 
ciated with said first and second devices are 
synchronized. 

2. Trie method in accordance with Claim 1 wherein 
said characteristic comprises a version of said 
firmware. 

3. The method in accordance with Claim 1 wherein 
said step of modifying comprises uploading said 
second firmware 10 said second device and install- 
ing said second firmware to said second device. 

4. The method in accordance with Claim 3 deluding 
the step of verifying the integrity of said second 
firmware before it is installed. 

5. The method in accordance with Claim 4 wherein 
said firmware comprises a load module having a 
private-key-based digital eignaiire associated 
therewith and said step of verifying comprises the 
step of verifying said private key with a public key. 

6- The method in accordance with Claim 4 wherein 
said step of verifying comprises the verifying a dig- 
ital signature. 

7. The method in accordance with Claim 1 wherein 
said first device comprises a server and said sec- 
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ond device comprises a die/it device. 

6. The method in accordance with Claim 1 including 
the Step of said first device transmitting information 
lo said second device location information tar s 
obtaining said second firmware. 

9. 



10. The method in accordance with Claim 8 inducting 

the steps of confirming if said second firmware is is 
property installed into said second memory, and it 
not, said firmware associated with said second 
device obtaining information regarding location 
information for obtaining said second firmware and 
re- associating said second firmware from said so 
location with said second device. 

11. The method in accordance with Claim 8 including 
the step of confirming the integrity of said second 
firmware before installing said firmware into said 25 
second memory. 

12. The method in accordance with Claim 1 including 
the step of preventing unwanted code from being 
introduced to said second device by verifying the 30 
integrity of said firmware before it is installed. 

13. The method in accordance with Claim 1 wherein 
first firmware and third firmware is associated with 
said second device, said third firmware permitting 35 
said second device to remain operational in at least 
one mode in the event of a failure in associating 
said second firmware with said second device, and 
wherein said step of associating said second 
firmware comprises replacing only said first 40 
firmware and not said third firmware with said sec- 
ond firmware. 

14. The method in accordance with CJafm 13 wherein in 
said at least one mode said second device is 45 
arranged to associate said second firmware, and in 
the event of a failure in said step of associating said 
second firmware, said method includes the step of 
said third firmware causing said second device to 
re-associate said second firmware with said second so 
device. 

15. A computer program product comprising: 



computer readable program code configured to 
cause a comoute/ to provide information 
regarding a characteristic of the firmware asso- 
ciated with said first device; 
computer readable program code configured to 
cause a computer to provide information 
regarding a characteristic of the firmware asso- 
ciated with sad second device; 
computer readable program code configured to 
cause a computer to compare said provided 
firmware information regarding a characteristic 
of said first and second devices to determine if 
said characteristics match; and 
computer readable program code configured to 
associate second firmware with said second 
device if said characteristics associated with 
said firmware of said first and second devices 
match, whereby said firmware associated with 
said first and second devices is synchronized. 

16. The computer program product in accordance with 
Claim 15 including computer readable program 
code configured to verify said second firmware 
before said second frmware is associated with said 
second device. 

17. The computer program product in accordance with 
Claim 16 wherein said computer readable program * 
code is configured to verify a private-key-based dig- 
ital signature associated with said second f irmware 
with a public key. 

18. The computer program product in accordance with 
Claim 15 including computer readable program 
code configured to load said second firmware into a 
first memory associated with said second device 
and then install said second firmware into a second 
memory associated with said second device. 

19. The computer program product in accordance with 
Claim 15 including computer readable program 
code configured to compare a first string represent- 
ing a version of firmware associated with said first 
device to a second string representing a version of 
firmware associated with said second device to 
determine if said characteristics are fie same. 

20. The computer program product in accordance with 
Claim 15 wherein said second device includes third 
firmware and said computer readable program 
code configured to associate said second firmware 
with said second device is configured to replace 
only said first and not third firmware associated with 
said second device with said second firmware. 

21. The computer program product in accordance with 
Claim 20 wherein said third firmware comprises 
computer readable program code for re-associating 



a computer usable medium having computer ss 
readable program code ernbodied therein for 
synchronizing firmware associated with a first 
device and a second device comprising: 



The method in accordance with Claim 8 including 
the step of loading said second firmware into a first 
memory associated with said second device and 10 
installing said second firmware into a second mem- 
ory associated with said second device. 
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said second f/rmvvare in the event said replacement 
is unsuccessful. 

22. The computer program product in accordance with 
Claim 15 inducing computer readable program 5 
code arranged to prevent the introduction of 
unwanted code to said second device by preventing 
association of said second firmware with said sec- 
ond device unless Ihe integrity of said firmware is 
verified. 10 



23. A computer network comprising: 

a least one client computer;, 
at least one server; 75 
means for determining if a first firmware asso- 
ciated with said at least one server is synchro- 
nized with a second firmware associated with 
said at least one client computer; artf 
means for associating third firmware with said $0 
at least one client computer in the event said 
first and second firmware is not synchronized- 
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